Conventional remote server management systems and techniques exist which enable system administrators and other authorized users to provision, configure, maintain, or otherwise manage a plurality of servers. For example, a business or other organization may deploy a relatively large number of servers to thereby provide a private intranet. In other examples, a provider may deploy a plurality of servers, which are then made available on an outsourced and/or as-needed basis to one or more customers. For example, in the latter examples, a business may not wish to maintain its own server infrastructure, and therefore may instead contract with a provider of server infrastructure to thereby obtain desired server resources.
In these and other relevant contexts, the various deployed servers may be large in number, and/or may be deployed in geographical locations which are remote from one another and/or from a system administrator of the deployed servers. Consequently, it may be prohibitively expensive or impossible for such system administrators to physically or personally be present at a physical location of a given server which may require service or other management functionality at a given point in time. Thus, as referenced above, various systems and techniques have been developed which enable remote, network-based server management, which therefore enables system administrators to manage a large number of deployed servers in a practical, cost-effective manner.
In particular, such remote server management may include the provisioning or re-provisioning of one or more servers of a plurality of remotely-managed servers. For example, such provisioning or re-provisioning may be implemented in the context of creating a plurality of clones or copies of a designated server, and/or in the context of migrating a designated server from a source platform to a destination or a target platform. For example, such migration and cloning may be implemented for the purpose of quickly and reliably creating similar or identical servers within the context of a plurality of deployed servers. In other examples, servers may be migrated for the purpose of utilizing different/better hardware platforms, and/or for taking advantage of server virtualization (e.g., for migrating a server from a physical server to a virtual server, or from a first virtual infrastructure to a second virtual infrastructure).
In order to implement the above and related functionalities, it is conventional to capture and otherwise utilize an image of the designated server that is to be migrated, cloned, or otherwise provisioned or re-provisioned. In such contexts, such a server image generally refers to one or more files and related data which include sufficient information describing an operating system (OS), application stack, configurations, and other characteristics of the imaged server to enable a reconstruction or re-instantiation of the designated server using a different server (or server platform).
In the above and other related contexts, such a server image may be captured through the use of well-known network-based boot techniques. For example, during normal startup operations, a given server may utilize a boot loader to implement local, predefined boot configuration settings, to thereby boot an installed operating system, and, thus, to thereby load or otherwise make available all installed applications, network connections, and any other available hardware or software which has been pre-designated for inclusion in the normal or default startup procedures of the server in question.
In order to capture a server image of such a server, a system administrator may circumvent the just-described startup procedures by preemptively executing a network boot of the server in question. Specifically, for example, the system administrator may utilize a management server to transmit a specialized file which itself provides an image of a boot execution environment. Inasmuch as this transmitted boot image file preempts the normal boot operations of the designated server, the transmitted image file may be referred to as a pre-boot image which thus defines a pre-boot execution environment. Generally, such a pre-boot image may include or represent a minimized or optimized version of the boot settings/configurations normally used to boot the designated server, along with relevant software which is used to capture the desired image of the designated server, for use thereof in the above-referenced migration, cloning, or other provisioning-related management functionalities. Known techniques exist for implementing the just-referenced pre-boot techniques over a network, including, e.g., the pre-boot execution environment (PXE) and associated pre-boot image transmitted using the trivial file transfer protocol (TFTP).
Thus, in the manner just described, a system administrator may execute a network-based boot of a designated server to be provisioned or re-provisioned, including the described utilization of a pre-boot image. Generally speaking, a size and content of each pre-boot image should be minimized as much as reasonably possible, so as, for example, to conserve valuable network resources, e.g., bandwidth and/or memory. For example, since the pre-boot image is generally only required to initiate a network boot process of an otherwise inactive server and associated operating system, and to thereafter capture the desired image of the server and associated operating system, a number of elements which might normally be used during a typical, local boot process may be reduced or omitted. Instead, only such elements as may be particularly necessary for accomplishing the above-described goals may be included in the pre-boot image (e.g., certain boot-critical drivers, or certain configuration settings necessary for initiating a boot process). Moreover, inclusion of such elements may be specific to (and therefore optimized for) a type of hardware and/or software platform associated with the designated server (e.g., certain server manufacturers may require different boot-critical drivers relative to one another). Thus, using these and other related techniques, pre-boot images may be minimized or otherwise optimized for executing a network boot of a particular, designated server.
However, in many cases a system administrator may be responsible for provisioning or re-provisioning a large number of servers, which may vary widely with respect to one another in terms of available hardware/software platforms. Consequently, in order to utilize minimized/optimized pre-boot images in the manner just described, the system administrator may be required to store or otherwise access a correspondingly large number of pre-boot images which are specific to the servers which the system administrator may be required to manage.
Maintaining such a large library of pre-boot images may be cumbersome, time-consuming, or otherwise inefficient for the system administrator, particularly in cases where the servers managed by the system administrator may change over time in type and/or number, and/or in cases where various ones of the pre-boot images may need to be updated over time. Moreover, other difficulties may arise; for example, since the pre-boot images are essentially static images, it may be difficult for the system administrator to consider or otherwise manage aspects of the various-managed servers which may vary in time and/or which may be unique to a given server. For example, it may be difficult for the system administrator to manage boot-related issues associated with a network connectivity of a given server, such as, for example, a network address of the server. Thus, for the above and other reasons, it may be difficult or inefficient for a system administrator to manage a relatively large number of remote, heterogeneous servers.